COMMENT ⊗   VALID 00006 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	.S(Knowledge Acquisition:# Overview,a global perspective)
C00009 00003	.SS(Knowledge acquisition in context)
C00014 00004	.ind knowledge base management
C00017 00005	.SS(System diagram)
C00020 00006	.SKIP TO LINE 1   << overview box>>
C00024 ENDMK
C⊗;
.S(Knowledge Acquisition:# Overview,a global perspective);
.BEGINSMALLQUOTE; INDENT 0,0,0;
.ONCE FLUSH RIGHT
The essence of knowledge is, having it, to apply it;
.ONCE FLUSH RIGHT
not having it, to confess your ignorance.
.ENDSMALLQUOTE(Confucius);
.SS(Introduction);
	Before describing the range of knowledge acquisition capabilities
in &&, there are a few introductory comments that will help to establish a
global perspective on what follows.  First, since the term "knowledge
acquisition" has been used
previously to describe a range of tasks, we characterize our view of it.


.SS(Perspective on knowledge acquisition);
	We view the interaction between the domain expert and the performance program
as %2interactive transfer of expertise%*.  We see it in terms of a teacher who
continually challenges a student with new problems to solve and carefully observes
the student's performance.  The teacher may interrupt to request a justification of
some particular step the student has taken in solving the problem or may challenge
the final result.  This process may uncover a fault in the student's knowledge of the
subject (the debugging phase) and result in the transfer of information to correct it
(the knowledge acquisition phase).
	Other approaches to knowledge acquisition can be compared to this by
considering their relative positions along two dimensions: (i) the sophistication of
their debugging facilities and (ii) the independence of their knowledge acquisition
mechanism.
	The simplest sort of debugging tool is characterized by a program like DDT,
which is totally passive (in the sense that it operates only in response to user
commands), is low level (since it operates at the level of machine or assembly
language), and knows nothing about the application domain of the program.
	Debuggers like BAIL [[Resier75] and {prlang INTERLISP}'s break package
[[Teitelman75] are a step up from this since they function at the level of programming
languages like {prlang SAIL} and {prlang INTERLISP}.
	The simple "how" and "why" commands in && represent another step, since they
function at the level of the control structure of the application program.  The
guided debugging which && can also provide (see chapter 5) represents yet another
step, since here the debugger is taking the initiative and has enough built-in
knowledge  about the control structure that it can track down the error.  It does
this by requesting from the expert an opinion on the validity of a few selected rules
from among the many that were invoked.
	Finally, at the most sophisticated level are knowledge-rich debuggers
like the one found in [[Brown78].  Here the program is active, high-level, and
informed about the application domain, and is capable of independently localizing
and characterizing  bugs.
	By independence of the knowledge acquisition mechanism, we mean the degree of
human cooperation necessary.  Much work on knowledge acquisition has emphasized a
highly autonomous mode of operation.  There is, for example, a large body of work
aimed at inducing the appropriate generalizations from a set of test data (see, e.g.,
[[Buchanan78] and [[Hayes-Roth77]).  In these efforts user interaction is limited to
presenting the program with the data and perhaps providing a brief description of the
domain in the form of values for a few key parameters; the program then functions
independently.
	Winston's work on concept formation [[Winston70] relied somewhat more heavily
on user interaction.  There the teacher was responsible for providing an appropriate
sequence of examples (and non-examples) of a concept.
	In describing our work, we have used the phrase "interactive transfer of
expertise" to indicate that we view knowledge acquisition as information transfer
from an expert to a program.  && does not attempt to derive new knowledge on its own,
but instead tries to "listen" as attentively as possible and comment appropriately,
to help the expert augment the knowledge base.  It thus requires the strongest
degree of cooperation from the expert.

.SS(Knowledge acquisition in context);
	&& is designed to work with performance programs that accommodate
inexact knowledge.  Such programs find their greatest utility in domains
where knowledge has not been extensively formalized.  In such domains there
are typically no unifying laws on which to base algorithmic methods;
instead there is a collection of informal knowledge based on accumulated
experience.  As a result,  an expert specifying a new rule in this domain
may be
codifying a piece of knowledge that has never previously been isolated and
expressed as such.  This process of explicating previously informal
knowledge is difficult, and anything which can be done to ease the task
will prove very useful.
	In response, we have emphasized knowledge acquisition in the
context of  shortcomings in the knowledge base.  To illustrate the utility
of this approach,
consider the difference between asking the expert
.STARTCENTERIT(1);
What should I know about bacteremia?
.ENDCENTERIT
and saying to him
.BEGINQUOTE;
Here is a case history for which you claim the performance program
incorrectly deduced the presence of pseudomonas.  Here is how it reached
its conclusions, and here are all the facts of the case.  Now, %2what is it
that you know that the performance program doesn't%*, which allows you to
avoid making that mistake?%*
.ENDQUOTE;
Consider how much more focused the second question is and how much easier
it would be to explicate the relevant knowledge.
.ind(|focus, in knowledge acquisition|);
	The focusing provided by the context is also an important aid to
&&.  In particular, it permits the system to build up a set of
.ind expectations
%2expectations%* concerning the knowledge to be expressed, facilitating
knowledge transfer and making possible several useful features illustrated
in the next chapter.
	This approach should be distinguished from the one commonly
described by the phrase %2knowledge as debugging%*, illustrated by the work
of [[Sussman75] and [[Goldstein74].  That technique suggests that an
important part of problem solving is knowing how to correct "nearly right"
solutions.  The emphasis there is on developing a taxonomy of
problem-solving errors and assembling a store of knowledge about
corresponding repairs.
There is some knowledge of this sort in &&'s knowledge acquisition
routines, but it is largely hand-tailored and designed to deal with details
of the performance program's operation.  More of it, and a more general
foundation for it, would add useful capabilities.  They would be distinct,
however, from the advantages illustrated here, which accrue from the
explication of knowledge in the context of an error.

.ind knowledge base management
.SS(Knowledge base management);
	A third aspect of the approach in && lies in viewing some elements of
knowledge base management in terms  of database management.  That
is, part of the task looks like the sort of data-structure manipulation that has
been the focus of previous work on databases (e.g., [[Sandewall75],
[[McLeod76], [[Johnson75]).  But our work differs in several respects.  For one
thing, it involves constructing an integral part of the high-performance
program, rather than simply a database from which information is retrieved.  In
most standard database tasks, the retrieval or storage of information is the
ultimate aim.  In &&, we are assembling large amounts of information that will be
used by the performance program and that will enable it to reason about the
domain.  Where database work concentrates solely on the management of facts, our
system is also concerned with the management of a set of inference rules.
	Another basic difference is the reliance
on meta-level knowledge.  Examples in later chapters will illustrate that
management of the knowledge base can be founded on both the system's access
to and  "understanding" of its own representations.
	Finally, our  system focuses primarily on making additions to the knowledge
base.∪∪Since deletion of structures can often be viewed as the inverse of
addition, and modification viewed as deletion followed by addition, little generality
is lost.∪Concentrating on this single operation will focus the discussion yet
still cover  most of the interesting problems.

.SS(System diagram);
	{YONFIG DETAILEDOVERLAY} offered one view of && and
its relation to the performance program.  "Zooming in" on the knowledge
acquisition box shown in that figure produces the view presented in 
{YONFIG KAOVKA}, which is a complete overview of the capabilities described
in chapters 5 and 6.  The figure shows both the processes (standard boxes)
and different repositories of knowledge (double-walled boxes) divided up
according to their conceptual appearance (rather than their physical
structure).  Both the "new schema acquisition" and "new instance
acquisition" are accomplished with the same body of code (described
in chapter 6).  Other paths of information flow have been omitted from this
diagram for the sake of clarity.  They will all be described in the next
two chapters.   Chapter 5 deals with acquisition of new inference rules
expressed in terms of known conceptual primitives (e.g., known attributes,
objects, and values), while acquisition of new conceptual primitives is
described in chapter 6.  As we will see, these two are related but 
distinct problems, each requiring substantial effort for solution.

	The final introductory point to be made is the mixed-initiative
nature of the &&-expert interaction.  In general, the user
indicates what he wants to do.  && then takes over and structures
the task, requesting information from the user and getting his approval
before taking any important steps.  Numerous examples of this will be
encountered in the next two chapters.
.SKIP TO LINE 1;   << overview box>>
.STARTFIG;
.BOXFIG;
		      KNOWLEDGE ACQUISITION
	    ⊂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂⊃
	    }                                       }
	    } ⊂π∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂π⊃                   }
	    } }}2              }}∂ ∂ ∂ ∂ ∂ ⊃        }
	    } }} schema-schema }}          ↓        }
	    } α%∀∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∀$ ⊂∂∂∂∂∂∂∂∂∂∂∂∂∂∂⊃  }
	    }         ⊂ ∂ ∂ ∂ ∂ ∂ } new schema   }  }
	    }         ↓           } acquisition  }  }
	    } ⊂π∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂π⊃ α%∂∂∂∂∂∂∂∂∂∂∂∂∂∂$  }
	    } }}1              }}∂ ∂ ∂ ∂ ∂ ⊃        }
	    } }}    schemata   }}          ↓        }
 KNOWLEDGE  } α%∀∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∀$ ⊂∂∂∂∂∂∂∂∂∂∂∂∂∂∂⊃  }
   BASE     }                     } new instance }  }
⊂π∂∂∂∂∂∂π⊃  }                ⊂ ∂ ∂} acquisition  }  }← ∂ EXPERT
}}0     }}←∂}∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ $    α%∂∂∂∂∂∂∂∂∂∂∂∂∂∂$  }[dialog]
}} facts}}  }    [knowledge                         }
}} -----}}  }     transfer]                         }
}} rules}}←∂}∂ ∂ ∂ ∂ ∂ ∂ ∂ ∂ ⊃    ⊂∂∂∂∂∂∂∂∂∂∂∂∂∂∂⊃  }
}}      }}  }                α% ∂ ∂}     rule     }  }
α%∀∂∂∂∂∂∂∀$  }                     }  acquisition }  }
            }                     α%∂∂∂∂∂∂∂∂∂∂∂∂∂∂$  }
    }       }  ⊂π∂∂∂∂∂∂∂∂∂∂∂∂∂π⊃          ↑         }
            }  }}1            }}                    }
    α% ∂ ∂ ∂ }∂→}}     rule    }}∂ ∂ ∂ ∂ ∂ $         }
 [concept   }  }}    models   }}    [model-directed }
  formation]}  α%∀∂∂∂∂∂∂∂∂∂∂∂∂∂∀$     understanding] }
            }                                       }
            α%∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂∂$
.skip
.LONGCAPFIG(Close-up view of knowledge acquisition, |Double-walled 
. boxes with numbers in the upper left-hand corner contain
. various sorts of knowledge; the number indicates the level of knowledge
. they contain.  The original performance program knowledge base is at the
. left with a "%50%*," indicating object-level knowledge.  Standard boxes
. without numbers indicate the three knowledge acquisition processes
. available for educating the system.  Dashed arrows indicate information
. flow and are labeled (in brackets) when that information flow has a
. familiar name.|, KAOVKA:);
.ENDFIG;

β